The present invention relates to methods, systems and apparatus for transmitting data in mobile telecommunications systems.
Mobile communication systems have evolved over the past ten years or so from the GSM System (Global System for Mobile communications) to the 3G system and now include packet data communications as well as circuit switched communications. The third generation partnership project (3GPP) is developing a fourth generation mobile communication system referred to as Long Term Evolution (LTE) in which a core network part has been evolved to form a more simplified architecture based on a merging of components of earlier mobile radio network architectures and a radio access interface which is based on Orthogonal Frequency Division Multiplexing (OFDM) on the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) on the uplink.
Third and fourth generation mobile telecommunication systems, such as those based on the 3GPP defined UMTS and Long Term Evolution (LTE) architectures, are able to support a more sophisticated range of services than simple voice and messaging services offered by previous generations of mobile telecommunication systems.
For example, with the improved radio interface and enhanced data rates provided by LTE systems, a user is able to enjoy high data rate applications such as mobile video streaming and mobile video conferencing that would previously only have been available via a fixed line data connection. The demand to deploy third and fourth generation networks is therefore strong and the coverage area of these networks, i.e. geographic locations where access to the networks is possible, is expected to increase rapidly.
The anticipated widespread deployment of third and fourth generation networks has led to the parallel development of a class of devices and applications which, rather than taking advantage of the high data rates available, instead take advantage of the robust radio interface and increasing coverage. One such class of device are machine-type-communication (MTC) devices supporting machine-to-machine (M2M) communications. Examples include so-called smart meters which, for example, are located in a customer's house and periodically transmit information back to a central MTC server data relating to the customer's consumption of a utility such as gas, water, electricity and so on. Further information on characteristics of MTC-type devices can be found, for example, in the corresponding standards, such as ETSI TS 122 368 V10.530 (2011-07)/3GPP TS 22.368 version 10.5.0 Release 10) [2]. MTC devices may in some respects be seen as devices which can be supported by relatively low bandwidth communication channels having relatively low quality of service (QoS), for example in terms of latency.
Whilst it can be convenient for a terminal such as an MTC-type terminal to take advantage of the wide coverage area provided by a third or fourth generation mobile telecommunication network there are at present some disadvantages associated with the use of existing network configuration for communicating MTC data. The minimisation of power consumption and complexity is a driving factor behind all third and fourth generation terminals, and even more so for MTC terminals because of desired low cost and placement in locations where access to a dedicated power source may be limited or not economically viable. Consequently, there is a desire to reduce the power consumption of MTC terminals.
A technique which has been incorporated into LTE to help manage power consumption is the so-called discontinuous reception (DRX) mode. DRX allows a terminal to stay in a sleep mode between paging cycles with the network and therefore conserve power. This is achieved by extending the period of a paging cycle to a device and the device waking up for the duration of a predetermined wake-up window after a sleep period to receive any paging information. This process can help relieve the terminal of frequent synchronisation and communication tasks with the network and the reduced operating burden can lead to an associated reduction in power consumption. Thus the DRX capability included in LTE-type systems enables devices to be brought out of a power saving idle state and re-establish communications with the network when needed.
Whilst the DRX operating mode can help reduce power consumption for terminals which might access the network only infrequently, there are nonetheless a number of drawbacks with this approach. Firstly, the maximum DRX cycle currently specified is relatively short, only around 2.5 seconds. However, it is expected that some types of terminal, for example MTC-type devices, might wish to communicate data much less frequently than this such that a longer potential period of inactivity could be more appropriate in some circumstances. Secondly, when a terminal device wakes up in accordance with a conventional DRX operating mode, the device must perform a number of steps before it is able to determine if the network has data for communication to the device.
For example, when operating in a conventional DRX mode and a DRX timer expires (i.e. when it is time for device to “wake up”), a device will commonly be required to undertake the following steps to retrieve user data.
Step 1: Frame Synchronization. The device searches for synchronization signals to achieve frame synchronization
Step 2: Reception of Master Information. The device determines the location of the Master Information Block (MIB) in the frame structure and decodes the MIB to determine channel bandwidth and System Frame Number (SFN) information.
Step 3: Reception of System Information. Taking account of SFN, the device determines the location of System Information Block(s) (SIB) in the frame structure and decodes SIB to obtain further system information
Step 4: Reception of Paging Message. The device searches for paging information that would indicate the presence of user data for the device on the relevant control channel (PDCCH).
Thus as part of each DRX cycle the device checks specific frames and subframes for paging messages from the network, the locations of paging messages and the DRX cycle of a device having been pre-negotiated between the device and the network. When a relevant paging message is received by a device, the device establishes a data connection with the network using established signalling and proceeds to transmit/receive the relevant data. However, as set out above, for the device to be able to do this it needs to first perform various steps including synchronising with the network's frame structure.
In some cases a device may not be required to perform all the above-mentioned steps on every DRX cycle. For example, for short DRX cycles, frame synchronisation could in principle be maintained from one DRX cycle to the next with sufficiently accurate timing. Furthermore, information such as MIB/SIB may in principle be stored at the device and assumed the same in different DRX cycles such that some of the four steps set out above may be abbreviated. However, for relatively long DRX cycles it is likely to be necessary to re-obtain this information for at least some, if not most, DRX cycles.
Because a device will generally perform the above-identified steps (or an abbreviated version of them) for every DRX cycle, there can still be a significant amount of power required to operate in a DRX mode, even during extended periods when there is no data to be communicated to the device.
One existing low power, short-range ad-hoc network protocol designed for low data-rate applications is ZigBee®. It is a protocol designed for use with mesh networks and has the capability to forward messages between devices and for devices to sleep between periods of activity. To further conserve node battery life the transfer of data between a coordinator device and a receiving device is primarily controlled by the receiving device as opposed to the coordinator device. The protocol for transferring data from a coordinator device to a receiving device is dependent upon whether the ZigBee network is beacon or non-beacon enabled. In a beacon-enabled network, the coordinator device indicates in a beacon that it wishes to transfer data to a receiving device. A receiving device periodically wakes up from its sleeping state, receives and utilises the beacon for synchronisation, and then checks for relevant messages from the coordinator device. If one is found, the receiving device requests that the coordinator device sends the data. In a non-beacon-enabled network, a receiving device periodically wakes from a sleeping state and requests any pending data from the coordinator device. If there is pending data the coordinator device acknowledges the request for transmission and then sends the data. If there is no pending data the coordinator informs the device and the device responds with an acknowledgement. This protocol allows devices to sleep for significant periods of time, but requires a number of two-way transmissions between the devices and the coordinator to establish communications regardless of whether or not there is data to be communicated. Furthermore, these modes of operation depart significantly from established wireless telecommunications principles and so could not be readily implemented in a wireless telecommunications system, such as an LTE-type network.
Some other types of network which allows a device to enter a sleep period/power saving mode are those based on the IEEE 802.11 standard, for example WiFi. In these networks a device may enter a sleep mode and the network access point maintains a list of all the devices that are currently sleeping. A beacon frame that contains information on pending data for sleeping devices is then periodically transmitted by the access point. Sleeping devices wake up and check this frame to learn whether there is data pending; if data is pending the devices poll the access point and initiate communications with the access point. Communications between the device and access point can also be re-established by the device informing the access point that it has woken-up from a sleep period. Although this procedure allows a device to sleep for periods of time and therefore save power, they still have to wake up at predefined times to check the beacon frame and then perform a number of two-way communications to establish a link with the network. Consequently, devices need to maintain synchronisation with the network in order to utilise the power saving mode and when a device does emerge from the power saving mode it incurs significant overheads. Furthermore, and as with ZigBee, these operating aspects of schemes based on the IEEE 802.11 standard depart significantly from established wireless telecommunications principles and so could not be readily implemented in a wireless telecommunications system, such as an LTE-type network
Thus although there are a number of established power saving techniques for devices which might infrequently receive only small quantities of data, there remains a need to provide improved schemes for reduced power operation for terminal devices operating in wireless telecommunications networks, for example MTC type devices operating in an LTE-type network.